0:00–0:10
Recap
0:10–0:40
Lecture
0:40–1:40
Guided Lab
1:40–1:50
Bonus
1:50–2:00
Debrief
0:00 – 0:10
Recap · 10 min
Day 1 review & the email authentication gap
- Ask: "What three mailbox types were created yesterday that don't require a licence?" — shared, room, equipment
- Ask: "In Lab 1-B you added an MX record and an SPF TXT record to your DNS zone. What does each one do for email?" — surface the existing foundation before building on it
- Ask: "SPF tells receiving mail servers which servers are authorised to send email for your domain. What is the gap — what can SPF not protect against?" — prime DKIM: SPF verifies the sending server but not that the message content wasn't tampered with in transit
- Frame the day: today completes the email authentication chain. SPF was Week 1. DKIM and DMARC are today. Together they form the standard that separates professional email infrastructure from an easy spoofing target.
0:10 – 0:40
Lecture · 30 min
How email authentication works — SPF, DKIM, DMARC, and mail flow
The lecture has two parts: the email authentication chain (15 min) and Exchange Online mail flow mechanics (15 min). Both are needed for today's lab.
Part A — The email authentication chain
SPF
Is this server allowed to send for this domain?
+
DKIM
Was this message signed by the domain?
+
DMARC
What to do if SPF or DKIM fails?
=
Trust
Full email authentication
- SPF (Sender Policy Framework) — already configured — a TXT record in DNS listing authorised sending servers. Receiving servers check the sending IP against this list. SPF passes or fails based on the sending server, not the message content. Students set this up in Lab 1-B: v=spf1 include:spf.protection.outlook.com -all.
- DKIM (DomainKeys Identified Mail) — Exchange Online generates a cryptographic key pair. The private key signs every outbound message with a digital signature embedded in the mail headers. The public key is published as a CNAME record in DNS. Receiving servers use the public key to verify the signature — confirming the message was sent by the domain and wasn't modified in transit. DKIM must be explicitly enabled in the Exchange admin centre for each custom domain.
- DMARC (Domain-based Message Authentication, Reporting & Conformance) — a TXT record in DNS that tells receiving servers what to do when a message fails SPF or DKIM: none (monitor only), quarantine (send to junk), or reject (discard the message). DMARC also includes a reporting address where receiving servers send aggregate and forensic reports. It requires at least one of SPF or DKIM to pass AND for the domain to align — meaning the domain in the From header matches the domain that passed SPF or DKIM.
- Why all three matter together — SPF alone can be bypassed if an attacker controls the sending server. DKIM alone doesn't prevent a compromised server from sending. DMARC without both SPF and DKIM has no enforcement teeth. Together, they make domain spoofing extremely difficult and give you visibility through DMARC reports when someone tries.
Part B — Exchange Online mail flow
- Inbound mail flow — external mail arrives at Exchange Online Protection (EOP), which applies anti-spam and anti-malware scanning before delivery to the recipient mailbox. The MX record points external senders to Exchange Online's inbound endpoint. If the MX record is wrong, inbound mail silently fails.
- Outbound mail flow — mail sent from Exchange Online exits through Microsoft's outbound relay infrastructure. DKIM signing is applied if enabled. SPF is satisfied because the sending IP is Microsoft's. DMARC is checked by the recipient's server.
- Connectors — connectors extend Exchange Online's mail routing to external systems. An inbound connector accepts mail from a specific source (e.g. an on-premises server or a third-party service). An outbound connector routes mail to a specific destination. Most cloud-only Exchange Online tenants don't need connectors — they are required for hybrid deployments or integration with on-premises services.
- Message Trace — the EAC's mail flow diagnostic tool. Traces the path of any message through Exchange Online — when it was received, what happened to it at each stage, whether it was delivered, quarantined, or rejected, and why. Indispensable for diagnosing delivery failures. Traces are available for up to 90 days.
Instructor note: Run a live MXToolbox lookup on the class subdomain (mxtoolbox.com/SuperTool) showing the MX record, SPF record, and DKIM record (which won't exist yet — students will add it in the lab). Show what "no DKIM" looks like before the lab begins so students can see the before/after. Run the same check at the end of the lab to show the DKIM CNAME records appearing.
0:40 – 1:40
Guided lab · 60 min
Lab 3-B: Completing the email authentication chain for Lakeview Logistics
Students enable DKIM signing, add the required CNAME records to their subdomain DNS zone, publish a DMARC policy, validate the full authentication chain externally, and use Message Trace to observe a live mail delivery event.
- Step 1 — Enable DKIM in the Exchange admin centre (10 min)
Navigate to admin.exchange.microsoft.com → Mail flow → DKIM (or Protection → DKIM depending on EAC version). Select your custom subdomain. Click Enable. Exchange Online will display two CNAME records that must be added to your DNS zone before DKIM will activate. Copy both CNAME records exactly — host name and value — into your Lab Journal. Do not close this page.
- Step 2 — Add DKIM CNAME records to DNS (10 min)
Open your DNS control panel. Add both CNAME records provided by the EAC. The records follow this format:
· Host: selector1._domainkey.[yoursubdomain] → Value: selector1-[tenant]._domainkey.[tenant].onmicrosoft.com
· Host: selector2._domainkey.[yoursubdomain] → Value: selector2-[tenant]._domainkey.[tenant].onmicrosoft.com
Set TTL to 300. Save both records. Return to the EAC DKIM page and click Enable again (or Refresh) — DKIM status should show as Enabled once DNS propagates. This may take a few minutes.
- Step 3 — Publish a DMARC TXT record (10 min)
In your DNS control panel, add a new TXT record:
· Host: _dmarc.[yoursubdomain]
· Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@[yoursubdomain]; ruf=mailto:dmarc-reports@[yoursubdomain]; fo=1
· TTL: 300
Start with p=none (monitor only) — never deploy DMARC with p=reject on day one without validating your mail flow first. The rua address receives aggregate reports. Record the full DMARC record value in your Lab Journal.
- Step 4 — Validate the full authentication chain externally (10 min)
Open mxtoolbox.com/SuperTool. Run the following checks on your subdomain and record the results:
· MX lookup — confirm points to Exchange Online
· TXT lookup — confirm SPF record present and correct
· DKIM lookup — enter selector1._domainkey.[yoursubdomain] — confirm the CNAME resolves
· DMARC lookup — enter _dmarc.[yoursubdomain] — confirm the DMARC record is found
Record all four results. If DKIM is still showing as not found, DNS hasn't propagated yet — check again in 5 minutes.
- Step 5 — Use Message Trace to observe a mail event (20 min)
In the EAC: Mail flow → Message trace → + Start a trace. Search for any mail sent to or from a mailbox in your tenant in the past 48 hours. If no real mail exists, send a test message first:
· Open outlook.office.com and sign in as Sarah Chen
· Send a test message to your own admin account
· Return to Message Trace and search for this message
Click into the trace result. Review the full delivery detail — timestamp, sending server, receiving endpoint, delivery status, and any processing actions. Record the delivery path in your Lab Journal.
DMARC reporting address note: The rua and ruf addresses in your DMARC record must be valid mailboxes in your tenant. The dmarc-reports@[yoursubdomain] address will only receive reports if you create a shared mailbox for it. For this lab, the address doesn't need to be a real mailbox — but in production this is essential. Flag this as a Day 3 task (creating the dmarc-reports shared mailbox).
Instructor note: DKIM activation is occasionally slow — the EAC may show "Pending" for several minutes after the CNAME records are added. Have students proceed to DMARC and validation in parallel, then circle back to verify DKIM status. If DKIM is still not active after 10 minutes, check the CNAME values entered in DNS character by character — the tenant-specific values are easy to truncate accidentally.
1:40 – 1:50
Bonus material · 10 min
⭐ Bonus: DMARC policy progression & mail flow analysis via PowerShell
⭐ Bonus A — DMARC policy progression
- The current DMARC policy is p=none (monitor only — no enforcement). Explain in your Lab Journal the three-stage DMARC deployment path: p=none → p=quarantine → p=reject
- What evidence would you want to see in DMARC aggregate reports before moving from p=none to p=quarantine? How long would you monitor?
- Update your DMARC record to add a subdomain policy: append ; sp=reject to the record value. This sets p=none for the root domain but p=reject for any subdomains that don't have their own DMARC record. Explain in your Lab Journal why this is a useful intermediate step.
- Verify the updated DMARC record in MXToolbox and record the full parsed result.
⭐ Bonus B — Mail flow analysis via PowerShell
- Connect to Exchange Online PowerShell: Connect-ExchangeOnline -UserPrincipalName admin@[yoursubdomain]
- Check DKIM signing configuration: Get-DkimSigningConfig | Select-Object Domain, Enabled, Status, Selector1CNAME, Selector2CNAME | Format-List
- Pull recent message traces via PowerShell (last 24 hours):
Get-MessageTrace -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) | Select-Object Received, SenderAddress, RecipientAddress, Subject, Status | Format-Table -AutoSize
- In your Lab Journal: what is the Status field showing for each message? What status values are possible and what does each one mean?
- Stretch: filter for only failed deliveries: ... | Where-Object {$_.Status -ne "Delivered"}
1:50 – 2:00
Debrief · 10 min
Reflection & preview
- Ask: "Your DMARC policy is currently p=none. An attacker sends an email to a customer spoofing your domain. What happens?" — answer: nothing enforced yet, but the aggregate report captures it. This is why you monitor before enforcing.
- Ask: "What would you need to check before changing DMARC from p=none to p=reject?" — surface the legitimate mail flow verification requirement: all authorised sending sources must pass SPF or DKIM
- Ask: "DKIM uses two selectors (selector1 and selector2). Why two? What is the other one for?" — surface key rotation: one selector is active, the other allows Microsoft to rotate the signing key without interrupting mail delivery
- Collect exit ticket: describe what happens step by step when an attacker sends an email spoofing your domain to an external recipient whose server enforces DMARC — trace through SPF check, DKIM check, DMARC alignment, and the policy action
- Preview Day 3: the authentication chain is complete. Day 3 moves to what happens after mail is delivered — anti-spam and anti-phishing policies, Safe Attachments, Safe Links, and quarantine management
Learning outcomes — by end of Day 2, students can…
Explain the auth chainDescribe SPF, DKIM, and DMARC — what each checks, what each protects against, and why all three are needed
Enable DKIM signingActivate DKIM for a custom domain in the EAC and add the required CNAME records to DNS
Publish a DMARC recordWrite and deploy a DMARC TXT record with correct syntax, reporting addresses, and p=none starting policy
Validate externallyUse MXToolbox to confirm MX, SPF, DKIM, and DMARC are all correctly published
Use Message TraceRun a message trace in the EAC and interpret the delivery path and status of a specific message
What you need ready
DNS control panel access (nw7.nat-acc.ca zones)
MXToolbox open on projector
Exchange Online PowerShell module
Slide deck: SPF+DKIM+DMARC chain diagram
Lab 3-B step sheet